Made some modifications to the description. There is no reason that Z homing cannot be done with the nozzle, and the utility of this feature is tied to a machine with a Z axis that must home to MAX, for one reason or another. This may be best for machines with a Z bed that homes to the bottom.

TODO: It makes sense to require Z_SAFE_HOMING for this feature because the behavior already encoded in home_z_safely will ensure that the probe is over the bed, at the position the user prefers. But, it will behave slightly differently, only applying home_z_safely for the second, probe-based, Z homing, not the first endstop-based Z homing, which presumably it matters not where the nozzle is in the XY plane.

@thinkyhead I agree with your changes and comments. I started an attempt for the flag to be just a function parameter, and unfortunately that opens a can of worms into other functions which seems to bloat the code worse than the global flag.... the global flag seems to follow suit with variables such as relative_mode and z_min_trusted which already existed... Maybe combining relative_mode and z_min_trusted and z_homing_use_probe into a single uint8_t later down the road and using bits for flags would be better, that would probably have to be evaluated though.

I have required Z_SAFE_HOMING as you have recommended, though the home_z_safely function is slightly different than needed during re-homing. home_z_safely does not move Z first to prevent dragging nozzle across the build plate. Also home_z_safely is not in a scope that can be called directly from motion.cpp, luckily all we need is just a Z move to probe deploy position, then XY to Z_SAFE_HOMING position, which is simple enough. A case could be made that instead of a recursive homeaxis call, we simply call it twice from G28.cpp, then home_z_safely is in scope, but also home_z_safely would need modified so that Z moves first, which may alter other functions that depend on home_z_safely to remain as it is. As the code is now everything works fine and home_z_safely is unmodified.

I also noticed TERN0 TERN1 and TERN only work for defines that are defined to 1 or undefined. Thus I had to fix a section of my code which use_probe_bump was not actually grabbing the value of Z_CLEARANCE_BETWEEN_PROBES when it should have. That issue is now also resolved.

I have tested the newly modified version of this code, running on my AnyCubic i3 Mega machines, and it is working well.